Controlling objects via gesturing

ABSTRACT

The present invention is directed toward a system and process that controls a group of networked electronic components using a multimodal integration scheme in which inputs from a speech recognition subsystem, gesture recognition subsystem employing a wireless pointing device and pointing analysis subsystem also employing the pointing device, are combined to determine what component a user wants to control and what control action is desired. In this multimodal integration scheme, the desired action concerning an electronic component is decomposed into a command and a referent pair. The referent can be identified using the pointing device to identify the component by pointing at the component or an object associated with it, by using speech recognition, or both. The command may be specified by pressing a button on the pointing device, by a gesture performed with the pointing device, by a speech recognition event, or by any combination of these inputs.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims the benefit of U.S.patent application Ser. No. 11/185,399, filed on Jul. 19, 2005 andentitled “SYSTEM AND PROCESS FOR CONTROLLING ELECTRONIC COMPONENTS IN AUBIQUITOUS COMPUTING ENVIRONMENT USING MULTIMODAL INTEGRATION”, (nowU.S. Pat. No. 7,552,403 issued on Jun. 23, 2009), which is acontinuation of and claims the benefit of U.S. patent application Ser.No. 10/160,659, filed on May 31, 2002, (now U.S. Pat. No. 6,990,639issued on Jan. 24, 2006), and which also claims the benefit of apreviously filed provisional patent application Ser. No. 60/355,368,filed on Feb. 7, 2002, each of which are incorporated herein in theirentirety by reference.

BACKGROUND

1. Technical Field

The invention is related to controlling electronic components in aubiquitous computing environment, and more particularly to a system andprocess for controlling the components using multimodal integration inwhich inputs from a speech recognition subsystem, gesture recognitionsubsystem employing a wireless pointing device and pointing analysissubsystem associated with the pointing device, are combined to determinewhat component a user wants to control and what control action isdesired.

2. Background Art

Increasingly our environment is populated with a multitude ofintelligent devices, each specialized in function. The modern livingroom, for example, typically features a television, amplifier, DVDplayer, lights, and so on. In the near future, we can look forward tothese devices becoming more inter-connected, more numerous and morespecialized as part of an increasingly complex and powerful integratedintelligent environment. This presents a challenge in designing gooduser interfaces.

For example, today's living room coffee table is typically clutteredwith multiple user interfaces in the form of infrared (IR) remotecontrols. Often each of these interfaces controls a single device.Tomorrow's intelligent environment presents the opportunity to present asingle intelligent user interface (UI) to control many such devices whenthey are networked. This UI device should provide the user a naturalinteraction with intelligent environments. For example, people havebecome quite accustomed to pointing at a piece of electronic equipmentthat they want to control, owing to the extensive use of IR remotecontrols. It has become almost second nature for a person in a modernenvironment to point at the object he or she wants to control, even whenit is not necessary. Take the small radio frequency (RF) key fobs thatare used to lock and unlock most automobiles in the past few years as anexample. Inevitably, a driver will point the free end of the key fobtoward the car while pressing the lock or unlock button. This is doneeven though the driver could just have well pointed the fob away fromthe car, or even pressed the button while still in his or her pocket,owing to the RF nature of the device. Thus, a single UI device, which ispointed at electronic components or some extension thereof (e.g., a wallswitch to control lighting in a room) to control these components, wouldrepresent an example of the aforementioned natural interaction that isdesirable for such a device.

There are some so-called “universal” remote controls on the market thatare preprogrammed with the known control protocols of a litany ofelectronic components, or which are designed to learn the commandprotocol of an electronic component. Typically, such devices are limitedto one transmission scheme, such as IR or RF, and so can control onlyelectronic components operating on that scheme. However, it would bedesirable if the electronic components themselves were passive in thatthey do not have to receive and process commands from the UI devicedirectly, but would instead rely solely on control inputs from theaforementioned network. In this way, the UI device does not have todifferentiate among various electronic components, say by recognizingthe component in some manner and transmitting commands using someencoding scheme applicable only to that component, as is the case withexisting universal remote controls.

Of course, a common control protocol could be implemented such that allthe controllable electronic components within an environment use thesame control protocol and transmission scheme. However, this wouldrequire all the electronic components to be customized to the protocoland transmission scheme, or to be modified to recognize the protocol andscheme. This could add considerably to the cost of a “singleUI-controlled” environment. It would be much more desirable if the UIdevice could be used to control any networked group of new or existingelectronic components regardless of remote control protocols ortransmission schemes the components were intended to operate under.

Another current approach to controlling a variety of differentelectronic components in an environment is through the use of speechrecognition technology. Essentially, a speech recognition program isused to recognize user commands. Once recognized the command can beacted upon by a computing system that controls the electronic componentsvia a network connection. However, current speech recognition-basedcontrol systems typically exhibit high error rates. Although speechtechnology can perform well under laboratory conditions, a 20%-50%decrease in recognition rates can be experienced when these systems areused in a normal operating environment. This decrease in accuracy occursfor the most part because of the unpredictable and variable noise levelsfound in a normal operating setting, and the way humans alter theirspeech patterns to compensate for this noise. In fact, environmentalnoise is currently viewed as a primary obstacle to the widespreadcommercialization of speech recognition systems.

It is noted that in the preceding paragraphs, as well as in theremainder of this specification, the description refers to variousindividual publications identified by a numeric designator containedwithin a pair of brackets. For example, such a reference may beidentified by reciting, “reference [1]” or simply “[1]”. Multiplereferences will be identified by a pair of brackets containing more thanone designator, for example, [2, 3]. A listing of references includingthe publications corresponding to each designator can be found at theend of the Detailed Description section.

SUMMARY

The present invention is directed toward a system and process thatcontrols a group of networked electronic components regardless of anyremote control protocols or transmission schemes under which theyoperate. In general this is accomplish using a multimodal integrationscheme in which inputs from a speech recognition subsystem, gesturerecognition subsystem employing a wireless pointing device and pointinganalysis subsystem also employing the pointing device, are combined todetermine what component a user wants to control and what control actionis desired.

In order to control one of the aforementioned electronic components, thecomponent must first be identified to the control system. In generalthis can be accomplished using the pointing system to identify thedesired component by pointing at it, or by employing speech recognition,or both. The advantage of using both is to reinforce the selection of aparticular component, even in a noisy environment where the speechrecognition system may operate poorly. Thus, by combining inputs theoverall system is made more robust. This use of divergent inputs toreinforce the selection is referred to as multimodal integration.

Once the object is identified, the electronic device can be controlledby the user informing the computer in some manner what he or she wantsthe device to do. This may be as simple as instructing the computer toturn the device on or off by activating a switch or button on thepointer. However, it is also desirable to control devices in morecomplex ways than merely turning them on or off. Thus, the user musthave some way of relaying the desired command to the computer. One suchway would be through the use of voice commands interpreted by the speechrecognition subsystem. Another way is by having the user perform certaingestures with the pointer that the computer will recognize as particularcommands. Integrating these approaches is even better as explainedpreviously.

In regard to the user performing certain gestures with the pointer toremotely convey a command, this can be accomplished in a variety ofways. One approach involves matching a sequence of sensor values outputby the pointer and recorded over a period of time, to stored prototypesequences each representing the output of the sensor that would beexpected if the pointer were manipulated in a prescribed manner. Thisprescribed manner is the aforementioned gesture.

The stored prototype sequences are generated in a training phase foreach electronic component it is desired to control via gesturing.Essentially to teach a gesture to the electronic component controlsystem that represents a particular control action for a particularelectronic component, a user simply holds down the pointer's buttonwhile performing the desired gesture. Meanwhile the electronic componentcontrol process is recording particular sensor values obtained fromorientation messages transmitted by the pointer during the time the useris performing the gesture. The recorded sensor values represent theprototype sequence.

During operation, the control system constantly monitors the incomingorientation messages once an object associated with a controllableelectronic component has been selected to assess whether the user isperforming a control gesture. As mentioned above, this gesturerecognition task is accomplished by matching a sequence of sensor valuesoutput by the pointer and recorded over a period of time, to storedprototype sequences representing the gestures taught to the system.

It is noted however, that a gesture made by a user during runtime maydiffer from the gesture preformed to create the prototype sequence interms of speed or amplitude. To handle this situation, the matchingprocess can entails not only comparing a prototype sequence to therecorded sensor values but also comparing the recorded sensor values tovarious versions of the prototype that are scaled up and down inamplitude and/or warped in time. Each version of the a prototypesequence is created by applying a scaling and/or warping factor to theprototype sequence. The scaling factors scale each value in theprototype sequence either up or down in amplitude. Whereas, the warpingfactors expand or contract the overall prototype sequence in time.Essentially, a list is established before initiating the matchingprocess which includes every combination of the scaling and warpingfactors possible, including the case where one or both of the scalingand warping factors are zero (thus corresponding to the unmodifiedprototype sequence).

Given this prescribed list, each prototype sequence is selected in turnand put through a matching procedure. This matching procedure entailscomputing a similarity indicator between the input sequence and theselected prototype sequence. The similarity indicator can be defined invarious conventional ways. However, in tested versions of the controlsystem, the similarity indicator was obtained by first computing a“match score” between corresponding time steps of the input sequence andeach version of the prototype sequence using a standard Euclideandistance technique. The match scores are averaged and the maximum matchscore is identified. This maximum match score is the aforementionedsimilarity indicator for the selected prototype sequence. Thus, theaforementioned variations in the runtime gestures are considered incomputing the similarity indicator. When a similarity indicator has beencomputed for every prototype sequence it is next determined which of thesimilarity indicators is the largest. The prototype sequence associatedwith the largest similarity indicator is the best match to the inputsequence, and could indicate the gesture associated with that sequencewas performed. However, unless the similarity is great enough, it mightbe that the pointer movements are random and do not match any of thetrained gestures. This situation is handled by ascertaining if thesimilarity indicator of the designated prototype sequence exceeds aprescribed similarity threshold. If the similarity indicator exceeds thethreshold, then it is deemed that the user has performed the gestureassociated with that designated prototype sequence. As such, the controlaction corresponding to that gesture is initiated by the host computer.If the similarity indicator does not exceed the threshold, no controlaction is initiated. The foregoing process is repeated continuously foreach block of sensor values obtained from the incoming orientationmessages having the prescribed length.

In regard to the use of simple and short duration gestures, such as forexample a single upwards or downwards motion, an opportunity exists toemploy a simplified approach to gesture recognition. For such gestures,a recognition strategy can be employed that looks for simple trends orpeaks in one or more of the sensor values output by the pointer. Forexample, pitching the pointer up may be detected by simply thresholdingthe output of the accelerometer corresponding to pitch. Clearly such anapproach will admit many false positives if run in isolation. However,in a real system this recognition will be performed in the context on anongoing interaction, during which it will be clear to system (and to theuser) when a simple pitch up indicates the intent to control a device ina particular way. For example, the system may only use the gesturerecognition results if the user is also pointing at an object, andfurthermore only if the particular gesture applies to that particularobject. In addition, the user can be required to press and hold down thepointer's button while gesturing. Requiring the user to depress thebutton while gesturing allows the system to easily determine when agesture begins. In other words, the system records sensor values onlyafter the user depresses the button, and thus gives a natural originfrom which to detect trends in sensor values. In the context ofgesturing while pointing at an object, this process induces a localcoordinate system around the object, so that “up”, “down”, “left” and“right” are relative to where the object appears to the user. Forexample, “up” in the context of a standing user pointing at an object onthe floor means pitching up from a pitched down position, and so on.

As discussed above, a system employing multimodal integration would havea distinct advantage over one system alone. To this end, the presentinvention includes the integration of a conventional speech controlsystem into the gesture control and pointer systems which results in asimple framework for combining the outputs of various modalities such aspointing to target objects and pushing the button on the pointer,pointer gestures, and speech, to arrive at a unified interpretation thatinstructs a combined environmental control system on an appropriatecourse of action. This framework decomposes the desired action into acommand and referent pair. The referent can be identified using thepointer to select an object in the environment as described previouslyor using a conventional speech recognition scheme, or both. The commandmay be specified by pressing the button on the pointer, or by a pointergesture, or by a speech recognition event, or any combination thereof.

The identity of the referent, the desired command and the appropriateaction are all determined by the multimodal integration of the outputsof the speech recognition system, gesture recognition system andpointing analysis processes using a dynamic Bayes network. Specifically,the dynamic Bayes network includes input, referent, command and actionnodes. The input nodes correspond to the aforementioned inputs and areused to provide state information to at least one of either thereferent, command, or action node. The states of the inputs determinethe state of the referent and command nodes, and the states of thereferent and command nodes are in turn fed into the action node, whosestate depends in part on these inputs and in part on a series of devicestate input nodes. The state of the action node indicates the actionthat is to be implemented to affect the referent. The referent, commandand action node states comprise probability distributions indicating theprobability that each possible referent, command and action is therespective desired referent, command and action.

In addition, the dynamic Bayes network preserves ambiguities from onetime step to the next while waiting for enough information to becomeavailable to make a decision as to what referent, command or action isintended. This is done via a temporal integration technique in whichprobabilities assigned to referents and commands in the last time stepare brought forward to the current time step and are input along withnew speech, pointing and gesture inputs to influence the probabilitydistribution computed for the referents and commands in the current timestep. In this way the network tends to hold a memory of a command andreferent, and it is thus unnecessary to specify the command and referentat exactly the same moment in time. It is also noted that the input fromthese prior state nodes is weighted such that their influence on thestate of the referent and command nodes decreases in proportion to theamount of time that has past since the prior state node first acquiredits current state.

The Bayes network architecture also allows the state of various devicesto be incorporated via the aforementioned device state input nodes. Inparticular, these nodes provide state information to the action nodethat reflects the current condition of an electronic componentassociated with the device state input node whenever the referent nodeprobability distribution indicates the referent is that component. Thisallows, as an example, the device state input nodes to input anindication of whether the associated electronic component is activatedor deactivated. This can be quite useful in situations where the onlyaction permitted in regard to an electronic component is to turn it offif it is on, and to turn it on if it is off. In such a situation, anexplicit command need not be determined. For example if the electroniccomponent is a lamp, all that need be known is that the referent is thislamp and that it is on or off. The action of turning the lamp on or off,as the case may be, follows directly, without the user ever having tocommand the system.

DESCRIPTION OF THE DRAWINGS

The specific features, aspects, and advantages of the present inventionwill become better understood with regard to the following description,appended claims, and accompanying drawings where:

FIG. 1 is a diagram depicting an object selection system according tothe present invention.

FIG. 2 is an image depicting one version of the wireless RF pointeremployed in the object selection system of FIG. 1, where the case istransparent revealing the electronic component within.

FIG. 3 is a block diagram illustrating the internal components includedin one version of the wireless RF pointer employed in the objectselection system of FIG. 1.

FIG. 4 is a flow chart diagramming a process performed by the pointer topackage and transmit orientation data messages.

FIG. 5 is a block diagram illustrating the internal components includedin one version of the RF base station employed in the object selectionsystem of FIG. 1.

FIG. 6 is a diagram depicting a general purpose computing deviceconstituting an exemplary system for implementing the host computer ofthe present invention.

FIG. 7 is a flow chart diagramming an overall process for selecting anobject using the object selection system of FIG. 1.

FIG. 8 is a flow chart diagramming a process for determining a set ofmagnetometer correction factors for use in deriving the orientation ofthe pointer performed as part of the overall process of FIG. 7.

FIG. 9 is a flow chart diagramming a process for determining a set ofmagnetometer normalization factors for use in deriving the orientationof the pointer performed as part of the overall process of FIG. 7.

FIGS. 10A-B depict a flow chart diagramming the process for deriving theorientation of the pointer performed as part of the overall process ofFIG. 7.

FIG. 11 is a timeline depicting the relative frequency of the productionof video image frames by the video cameras of the system of FIG. 1 andthe short duration flash of the IR LED of the pointer.

FIGS. 12A-B are images respectively depicting an office at IRfrequencies from each of two IF pass-filtered video cameras, whichcapture the flash of the IR LED of the pointer.

FIGS. 12C-D are difference images of the same office as depicted inFIGS. 12A-B where FIG. 12C depicts the difference image derived from apair of consecutive images generated by the camera that captured theimage of FIG. 12A and where FIG. 12D depicts the difference imagederived from a pair of consecutive images generated by the camera thatcaptured the image of FIG. 12B. The difference images attenuatebackground IR leaving the pointer's IR LED flash as the predominantfeature of the image.

FIG. 13 depicts a flow chart diagramming the process for determining thelocation of the pointer performed as part of the overall process of FIG.7.

FIG. 14 is a flow chart diagramming a first process for using the objectselection system of FIG. 1 to model an object in an environment, such asa room, as a Gaussian blob.

FIG. 15 is a flow chart diagramming an alternate process for using theobject selection system of FIG. 1 to model an object in an environmentas a Gaussian blob.

FIG. 16 depicts a flow chart diagramming a process for determining whatobject a user is pointing at with the pointer as part of the overallprocess of FIG. 7.

FIG. 17 is a flow chart diagramming a process for teaching the system ofFIG. 1 to recognize gestures performed with the pointer that representcontrol actions for affecting an electronic component corresponding toor associated with a selected object.

FIG. 18 depicts a flow chart diagramming one process for controlling anelectronic component by performing gestures with the pointer using thesystem of FIG. 1.

FIG. 19 depicts a flow chart diagramming another process for controllingan electronic component by performing gestures with the pointer usingthe system of FIG. 1.

FIGS. 20A-B depict a flowchart diagramming a procedure for gesturerecognition based on a thresholding technique.

FIG. 21 is a network diagram illustrating a dynamic Bayes network usedto integrate inputs from the system of FIG. 1 (both via pointing andgesturing), speech, past beliefs and electronic component states todetermine the desired referent and command, and then to use thesedeterminations, along with the component state information, to determinean appropriate action for affecting a selected electronic component.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following description of the preferred embodiments of the presentinvention, reference is made to the accompanying drawings which form apart hereof, and in which is shown by way of illustration specificembodiments in which the invention may be practiced. It is understoodthat other embodiments may be utilized and structural changes may bemade without departing from the scope of the present invention.

In general, the present electronic component control system and processinvolves the integration of a unique wireless pointer-based objectselection system, a unique gesture recognition system that employs thewireless pointer, and a conventional speech control system to create amultimodal interface for determining what component a user wants tocontrol and what control action is desired.

The pointer-based object selection system will be described first in thesections to follow, followed by the gesture recognition system, andfinally the integration of these systems with a conventional speechrecognition system to form the present electronic component controlsystem.

1.0 Object Selection Using a Wireless Pointer

In general, the present multimodal interface control system requires anobject selection system that is capable of allowing a user to point apointing device (referred to as a pointer) at an object in theenvironment that is, or is associated with, an electronic component thatis controllable by the control system, and by computing the orientationand location of the pointer in terms of the environment's pre-definedcoordinate system, can determine that the user is pointing at theobject. Any object selection system meeting the foregoing criteria canbe used. One such system is the subject of a co-pending U.S. patentapplication entitled “A SYSTEM AND PROCESS FOR SELECTING OBJECTS IN AUBIQUITOUS COMPUTING ENVIRONMENT”, having a Ser. No. 11/020,064, and afiling date of Dec. 20, 2004. Referring to FIG. 1, the object selectionsystem described in the co-pending application employs a wirelesspointer 10, which is pointed by a user at an object in the surroundingenvironment (such as a room) that the user wishes to affect. Forexample, the user might point the device 10 at a lamp with the intentionof turning the lamp on or off. The wireless pointer 10 transmits datamessages to a RF transceiver base station 12, which is in communicationwith a host computer 14, such as a personal computer (PC). In testedversions of the object selection system, communications between the basestation 12 and the host computer 14 were accomplished serially via aconventional RS232 communication interface. However, other communicationinterfaces can also be employed as desired. For example, thecommunications could be accomplished using a Universal System Bus (USB),or IEEE 1394 (Firewire) interface, or even a wireless interface. Thebase station 12 forwards data received from the pointer 10 to the hostcomputer 14 when a data message is received. The host computer 14 thencomputes the current 3D orientation of the pointer 10 from theaforementioned received data. The process used for this computation willbe described in detail later.

The object selection system also includes components for determining the3D location of the pointer 10. Both the orientation and location of thepointer within the environment in which it is operating are needed todetermine where the user is pointing the device. In tested embodimentsof the system these components included a pair of video cameras 16, 18with infrared-pass filters. These cameras 16, 18 are mounted at separatelocations within the environment such that each images the portion ofthe environment where the user will be operating the pointer 10 from adifferent viewpoint. A wide angle lens can be used for this purpose ifnecessary. Each camera 16, 18 is also connected via any conventionalwireless or wired pathway to the host computer 14, so as to provideimage data to the host computer 14. In tested embodiments of the system,the communication interface between the each camera 16, 18 and the hostcomputer 14 was accomplished using a wired IEEE 1394 (i.e., Firewire)interface. The process by which the 3D location of the pointer 10 isdetermined using the image data provided from the cameras 16, 18 willalso be discussed in detail later.

The aforementioned wireless pointer is a small hand-held unit that inthe tested versions of the object selection system resembled acylindrical wand, as shown in FIG. 2. However, the pointer can take onmany other forms as well. In fact the pointer can take on any shape thatis capable of accommodating the internal electronics and externalindicator lights and actuators associated with the device—althoughpreferably the chosen shape should be amenable to being pointed with areadily discernable front or pointing end. Some examples of possiblealternate shapes for the pointer would include one resembling a remotecontrol unit for a stereo or television, or one resembling an automobilekey fob, or one resembling a writing pen.

In general, the wireless pointer is constructed from a case having thedesired shape, which houses a number of off-the-shelf electroniccomponents. Referring to the block diagram of FIG. 3, the generalconfiguration of these electronic components will be described. Theheart of the pointer is a PIC microcontroller 300 (e.g., a PIC 16F873 20MHz Flash programmable microcontroller), which is connected to severalother components. For example, the output of an accelerometer 302, whichproduces separate x-axis and y-axis signals (e.g., a 2-axis MEMsaccelerometer model number ADXL202 manufactured by Analog Devices, Inc.of Norwood Mass.) is connected to the microcontroller 300. The output ofa magnetometer 304 (e.g., a 3-axis magnetoresistive permalloy filmmagnetometer model number HMC1023 manufactured by Honeywell SSEC ofPlymouth, Minn.), which produces separate x, y and z axis signals, isalso connected to the microcontroller 300, as can be an optional singleaxis output of a gyroscope 306 (e.g., a 1-axis piezoelectric gyroscopemodel number ENC-03 manufactured by Murata Manufacturing Co., Ltd. ofKyoto, Japan). The block representing the gyroscope in FIG. 3 has dashedlines to indicate it is an optional component.

There is also at least one manually-operated switch connected to themicrocontroller 300. In the tested versions of the wireless pointer,just one switch 308 was included, although more switches could beincorporated depending on what functions it is desired to make availablefor manual activation or deactivation. The included switch 308 is apush-button switch; however any type of switch could be employed. Ingeneral, the switch (i.e., button) 308 is employed by the user to tellthe host computer to implement some function. The particular functionwill be dependent on what part of the object selection system process iscurrently running on the host computer. For example, the user mightdepress the button to signal to the host computer that user is pointingat an object he or she wishes to affect (such as turning it on or off ifit is an electrical device), when the aforementioned process is in anobject selection mode. A transceiver 310 with a small antenna 312extending therefrom, is also connected to and controlled by themicrocontroller 300. In tested versions of the pointer, a 418 MHz, 38.4kbps bi-directional, radio frequency transceiver was employed.

Additionally, a pair of visible spectrum LEDs 314, 316, is connected tothe microcontroller 300. Preferably, these LEDs each emit a differentcolor of light. For example, one of the LEDs 314 could produce redlight, and the other 316 could produce green light. The visible spectrumLEDs 314, 316 can be used for a variety of purposes preferably relatedto providing status or feedback information to the user. In the testedversions of the object selection system, the visible spectrum LEDs 314,316 were controlled by commands received from the host computer via thebase station transceiver. One example of their use involves the hostcomputer transmitting a command via the base station transceiver to thepointer instructing the microcontroller 300 to illuminate the green LED316 when the device is being pointed at an object that the host computeris capable of affecting, and illuminating the red LED when it is not. Inaddition to the pair of visible LEDs, there is an infrared (IR) LED 318that is connected to and controlled by the microcontroller 300. The IRLED can be located at the front or pointing end of the pointer. It isnoted that unless the case of the pointer is transparent to visibleand/or IR light, the LEDs 314, 316, 318 whose light emissions would beblocked are configured to extend through the case of the pointer so asto be visible from the outside. It is further noted that a vibrationunit such as those employed in pagers could be added to the pointer sothat the host computer could activate the unit and thereby attract theattention of the user, without the user having to look at the pointer.

A power supply 320 provides power to the above-described components ofthe wireless pointer. In tested versions of the pointer, this powersupply 320 took the form of batteries. A regulator in the power supply320 converts the battery voltage to 5 volts for the electroniccomponents of the pointer. In tested versions of the pointer about 52 mAwas used when running normally, which decreases to 1 mA when the deviceis in a power saving mode that will be discussed shortly.

Tested versions of the wireless pointer operate on a command-responseprotocol between the device and the base station. Specifically, thepointer waits for a transmission from the base station. An incomingtransmission from the base station is received by the pointer'stransceiver and sent to the microcontroller. The microcontroller ispre-programmed with instructions to decode the received messages and todetermine if the data contains an identifier that is assigned to thepointer and which uniquely identifies the device. This identifier ispre-programmed into the microcontroller. If such an identifier is foundin the incoming message, then it is deemed that the message is intendedfor the pointer. It is noted that the identifier scheme allows otherdevices to be contacted by the host computer via the base station. Suchdevices could even include multiple pointers being operated in the sameenvironment, such as in an office. In the case where multiple pointerare in use in the same environment, the object selection process whichwill be discussed shortly can be running as multiple copies (one foreach pointer) on the same host computer, or could be running on separatehost computers. Of course, if there are no other devices operating inthe same environment, then the identifier could be eliminated and everymessage received by the pointer would be assumed to be for it. Theremainder of the data message received can include various commands fromthe host computer, including a request to provided orientation data in areturn transmission. In tested versions of the object selection system,a request for orientation data was transmitted 50 times per second(i.e., a rate of 50 Hz). The microcontroller is pre-programmed torecognize the various commands and to take specific actions in response.

For example, in the case where an incoming data message to the pointerincludes a request for orientation data, the microcontroller would reactas follows. Referring to the flow diagram in FIG. 4, the microcontrollerfirst determines if the incoming data message contains an orientationdata request command (process action 400). If not, the microcontrollerperforms any other command included in the incoming data message andwaits for the next message to be received from the base station (processaction 402). If, however, the microcontroller recognizes an orientationdata request command, in process action 404 it identifies the last-readoutputs from the accelerometer, magnetometer and optionally thegyroscope (which will hereafter sometimes be referred to collectively as“the sensors”). These output values, along with the identifier assignedto the pointer (if employed), and optionally the current state of thebutton and error detection data (e.g., a checksum value), are packagedby the microcontroller into an orientation data message (process action406). The button state is used by the host computer of the system forvarious purposes, as will be discussed later. The orientation datamessage is then transmitted via the pointer's transceiver to the basestation (process action 408), which passes the data on to the hostcomputer. The aforementioned orientation message data can be packagedand transmitted using any appropriate RF transmission protocol.

It is noted that while tested versions of the object selection systemused the above-described polling scheme where the pointer provided theorientation data message in response to a transmitted request, this neednot be the case. For example, alternately, the microcontroller of thepointer could be programmed to package and transmit an orientationmessage on a prescribed periodic basis (e.g., at a 50 Hz rate).

The aforementioned base station used in the object selection system willnow be described. In one version, the base station is a small,stand-alone box with connections for DC power and communications withthe PC, respectively, and an external antenna. In tested versions of theobject selection system, communication with the PC is done serially viaa RS232 communication interface. However, other communication interfacescan also be employed as desired. For example, the PC communicationscould be accomplished using a Universal System Bus (USB), or IEEE 1394(Firewire) interface, or even a wireless interface. The antenna isdesigned to receive 418 MHz radio transmissions from the pointer.

Referring now to the block diagram of FIG. 5, the general constructionof the RF transceiver base station will be described. The antenna 502sends and receives data message signals. In the case of receiving a datamessage from the pointer, the radio frequency transceiver 500demodulates the received signal for input into a PIC microcontroller504. The microcontroller 504 provides an output representing thereceived data message each time one is received, as will be describedshortly. A communication interface 506 converts microcontroller voltagelevels to levels readable by the host computer. As indicated previously,the communication interface in tested versions of the base stationconverts the microcontroller voltage levels to RS232 voltages. Power forthe base station components is provided by power supply 508, which couldalso be battery powered or take the form of a separate mains powered ACcircuit.

It is noted that while the above-described version of the base stationis a stand-alone unit, this need not be the case. The base station couldbe readily integrated into the host computer itself. For example, thebase station could be configured as an expansion card which is installedin an expansion slot of the host computer. In such a case only theantenna need be external to the host computer.

The base station is connected to the host computer, as describedpreviously. Whenever an orientation data message is received from thepointer it is transferred to the host computer for processing. However,before providing a description of this processing, a brief, generaldescription of a suitable computing environment in which this processingmay be implemented and of the aforementioned host computer, will bedescribed in more detail. It is noted that this computing environment isalso applicable to the other processes used in the present electroniccomponent control system, which will be described shortly. FIG. 6illustrates an example of a suitable computing system environment 100.The computing system environment 100 is only one example of a suitablecomputing environment and is not intended to suggest any limitation asto the scope of use or functionality of the invention. Neither shouldthe computing environment 100 be interpreted as having any dependency orrequirement relating to any one or combination of components illustratedin the exemplary operating environment 100.

The object selection process is operational with numerous other generalpurpose or special purpose computing system environments orconfigurations. Examples of well known computing systems, environments,and/or configurations that may be suitable for use with the inventioninclude, but are not limited to, personal computers, server computers,hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like (which are collectively be referred to ascomputers or computing devices herein).

The object selection process may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, etc. that performparticular tasks or implement particular abstract data types. Theinvention may also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules may be located in both local and remotecomputer storage media including memory storage devices.

With reference to FIG. 6, an exemplary system for implementing theinvention includes a general purpose computing device in the form of acomputer 110. Components of computer 110 may include, but are notlimited to, a processing unit 120, a system memory 130, and a system bus121 that couples various system components including the system memoryto the processing unit 120. The system bus 121 may be any of severaltypes of bus structures including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such architecturesinclude Industry Standard Architecture (ISA) bus, Micro ChannelArchitecture (MCA) bus, Enhanced ISA (EISA) bus, Video ElectronicsStandards Association (VESA) local bus, and Peripheral ComponentInterconnect (PCI) bus also known as Mezzanine bus.

Computer 110 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 110 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by computer 110. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of the any of the aboveshould also be included within the scope of computer readable media.

The system memory 130 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 131and random access memory (RAM) 132. A basic input/output system 133(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 110, such as during start-up, istypically stored in ROM 131. RAM 132 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 120. By way of example, and notlimitation, FIG. 6 illustrates operating system 134, applicationprograms 135, other program modules 136, and program data 137.

The computer 110 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 6 illustrates a hard disk drive 141 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 151that reads from or writes to a removable, nonvolatile magnetic disk 152,and an optical disk drive 155 that reads from or writes to a removable,nonvolatile optical disk 156 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 141 is typically connectedto the system bus 121 through a non-removable memory interface such asinterface 140, and magnetic disk drive 151 and optical disk drive 155are typically connected to the system bus 121 by a removable memoryinterface, such as interface 150.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 6, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 110. In FIG. 6, for example, hard disk drive 141 is illustratedas storing operating system 144, application programs 145, other programmodules 146, and program data 147. Note that these components can eitherbe the same as or different from operating system 134, applicationprograms 135, other program modules 136, and program data 137. Operatingsystem 144, application programs 145, other program modules 146, andprogram data 147 are given different numbers here to illustrate that, ata minimum, they are different copies. A user may enter commands andinformation into the computer 110 through input devices such as akeyboard 162 and pointer 161, commonly referred to as a mouse, trackballor touch pad. Other input devices (not shown) may include a microphone,joystick, game pad, satellite dish, scanner, or the like. These andother input devices are often connected to the processing unit 120through a user input interface 160 that is coupled to the system bus121, but may be connected by other interface and bus structures, such asa parallel port, game port or a universal serial bus (USB). A monitor191 or other type of display device is also connected to the system bus121 via an interface, such as a video interface 190. In addition to themonitor, computers may also include other peripheral output devices suchas speakers 197 and printer 196, which may be connected through anoutput peripheral interface 195. Further, a camera 163 (such as adigital/electronic still or video camera, or film/photographic scanner)capable of capturing a sequence of images 164 can also be included as aninput device to the personal computer 110. While just one camera isdepicted, multiple cameras could be included as input devices to thepersonal computer 110. The images 164 from the one or more cameras areinput into the computer 110 via an appropriate camera interface 165.This interface 165 is connected to the system bus 121, thereby allowingthe images to be routed to and stored in the RAM 132, or one of theother data storage devices associated with the computer 110. However, itis noted that image data can be input into the computer 110 from any ofthe aforementioned computer-readable media as well, without requiringthe use of the camera 163.

The computer 110 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer180. The remote computer 180 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 110, although only a memory storage device 181 has beenillustrated in FIG. 6. The logical connections depicted in FIG. 6include a local area network (LAN) 171 and a wide area network (WAN)173, but may also include other networks. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet.

When used in a LAN networking environment, the computer 110 is connectedto the LAN 171 through a network interface or adapter 170. When used ina WAN networking environment, the computer 110 typically includes amodem 172 or other means for establishing communications over the WAN173, such as the Internet. The modem 172, which may be internal orexternal, may be connected to the system bus 121 via the user inputinterface 160, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 110, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 6 illustrates remoteapplication programs 185 as residing on memory device 181. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

The exemplary operating environment having now been discussed, theremaining part of this description section will be devoted to adescription of the program modules embodying the object selectionprocess performed by the host computer. Generally, referring to FIG. 7,the object selection process begins by inputting the raw sensor readingsprovided in an orientation message forwarded by the base station(process action 700). These sensor readings are normalized (processaction 702) based on factors computed in a calibration procedure, andthen combined to derive the full 3D orientation of the pointer (processaction 704). Then, the 3D location of the pointer in the environment inwhich it is operating is computed (process action 706). Once theorientation and location of the pointer is known, the object selectionprocess determines what the pointer is being pointed at within theenvironment (process action 708), so that the object can be affected insome manner. The process then waits for another orientation message tobe received (process action 710) and repeats process actions 700 through710.

The object selection process requires a series of correction andnormalization factors to be established before it can compute theorientation of the pointer from the raw sensor values provided in anorientation message. These factors are computed in a calibrationprocedure. The first part of this calibration procedure involvescomputing correction factors for each of the outputs from themagnetometer representing the three axes of the 3-axis device,respectively. Correction factors are needed to relate the magnetometeroutputs, which are a measure of deviation from the direction of theEarth's magnetic field referred to as magnetic north (specifically thedot product of the direction each axis of the magnetometer is pointedwith the direction of magnetic north), to the coordinate frameestablished for the environment in which the pointer is operating. Thecoordinate frame of the environment is arbitrary, but must bepre-defined and known to the object selection process prior toperforming the calibration procedure. For example, if the environment isa room in a building, the coordinate frame might be establish such thatthe origin is in a corner with one axis extending vertically from thecorner, and the other two horizontally along the two walls forming thecorner.

Referring to FIG. 8, the magnetometer correction factors are computed bythe user first indicating to the object selection process that acalibration reading is being taken, such as for instance, by the userputting the object selection process running on the host computer into amagnetometer correction factor calibration mode (process action 800).The user then points the pointer in a prescribed direction within theenvironment, with the device being held in a known orientation (processaction 802). For example, for the sake of the user's convenience, thepre-determined direction might be toward a wall in the front of the roomand the known orientation horizontal, such that a line extending fromthe end of the pointer intersects the front wall of the roomsubstantially normal to its surface. If the pre-defined coordinatesystem of the environment is as described in the example above, then thepointer would be aligned with the axes of this coordinate system, thussimplifying the correction and normalization factor computations. Theuser activates the switch on the pointer when the device is pointed inthe proper direction with the proper orientation (process action 804).Meanwhile, the object selection process requests the pointer provide anorientation message in the manner discussed previously (process action806). The object selection process then inputs the orientation messagetransmitted by the pointer to determine if the switch status indicatorindicates that the pointer's switch has been activated (process action808). If not, the requesting and screening procedure continues (i.e.,process actions 806 and 808 are repeated). However, when an orientationmessage is received in which the button indicator indicates the buttonhas been depressed, then it is deemed that the sensor readings containedtherein reflect those generated when the pointer is pointing in theaforementioned prescribed direction and with the prescribed orientation.The magnetometer readings contained in the orientation message reflectthe deviation of each axis of the magnetometer from magnetic northwithin the environment and represent the factor by which each subsequentreading is offset to relate the readings to the environment's coordinateframe rather than the magnetometer axes. As such, in process action 810,the magnetometer reading for each axis is designated as the magnetometercorrection factor for that axis.

In addition to computing the aforementioned magnetometer correctionfactors, factors for range-normalizing the magnetometer readings arealso computed in the calibration procedure. Essentially, thesenormalization factors are based on the maximum and minimum outputs thateach axis of the magnetometer is capable of producing. These values areused later in a normalization procedure that is part of the process fordetermining the orientation of the pointer. A simple way of obtainingthese maximum and minimum values is for the user to wave the pointerabout while the outputs of the magnetometer are recorded by the hostcomputer. Specifically, referring to FIG. 9, the user would put theobject selection process running on the host computer in a magnetometermax/min calibration mode (process action 900), and then wave the pointerabout (process action 902). Meanwhile, the object selection processrequests the pointer to provide orientation messages in the normalmanner (process action 904). The object selection process then inputsand records the magnetometer readings contained in each orientationmessage transmitted by the pointer (process action 906). This recordingprocedure (and presumably the pointer waving) continues for a prescribedperiod of time (e.g., about 1 minute) to ensure the likelihood that thehighest and lowest possible readings for each axis are recorded. Oncethe recording procedure is complete, the object selection processselects the highest reading recorded for each axis of the magnetometerand designates these levels as the maximum for that axis (process action908). Similarly, the host computer selects the lowest reading recordedfor each axis of the magnetometer and designates these levels as theminimum for that axis (process action 910). Normalization factors arethen computed via standard methods and stored for each magnetometer axisthat convert the range represented by the maximum and minimum levels toa normalized range between 1.0 and −1.0 (process action 912). Thesemagnetometer normalization factors are used to normalize the actualreadings from the magnetometer by converting the readings to normalizedvalues between 1.0 and −1.0 during a normalization procedure to bediscussed shortly. It is noted that the maximum and minimum values foran axis physically correspond to that axis of the magnetometer beingdirected along magnetic north and directly away from magnetic north,respectively. It is noted that while the foregoing waving procedure isvery simple in nature, it worked well in tested embodiments of theobject selection system and provided accurate results.

Factors for range-normalizing (in [−1,1]) the accelerometer readings arealso computed in the calibration procedure. In this case, thenormalization factors are determined using the accelerometer outputnormalization procedures applicable to the accelerometer used, such asthe conventional static normalization procedure used in testedembodiments of the object selection process.

Once the calibration procedure is complete, the object selection processis ready to compute the orientation of the pointer each time anorientation data message is received by the host computer. Theorientation of the pointer is defined in terms of its pitch, roll andyaw angle about the respective x, y and z axes of the environment'spre-defined coordinate system. These angles can be determined viavarious sensor fusion processing schemes that essentially compute theangle from the readings from the accelerometer and magnetometer of thepointer. Any of these existing methods could be used, however asimplified procedure was employed in tested versions of the objectselection system. In this simplified procedure, the yaw angle iscomputed using the recorded values of the magnetometer output. Eventhough the magnetometer is a 3-axis device, the pitch, roll and yawangles cannot be computed directly from the recorded magnetometer valuescontained in the orientation data message. The angles cannot be computeddirectly because the magnetometer outputs a value that is thedot-product of the direction of each magnetometer sensor axis againstthe direction of magnetic north. This information is not sufficient tocalculate the pitch, roll, and yaw of the device. However, it ispossible to use the accelerometer readings in conjunction with themagnetometer outputs to compute the orientation. Specifically, referringto FIGS. 10A and B, the first action in the procedure is to normalizethe magnetometer and accelerometer values received in the orientationmessage using the previously computed normalization factors to simplifythe calculations (process action 1000). The pitch and roll angles of thepointer are then computed from the normalized x-axis and y-axisaccelerometer values, respectively (process action 1002). Specifically,the pitch angle=−arcsin(a₁), where a₁ is the normalized output of theaccelerometer approximately corresponding to the rotation of the pointerabout the x-axis of the environment's coordinate system, and the rollangle=−arcsin(a₂) where a₂ is the normalized output of the accelerometerapproximately corresponding to the rotation of the pointer about they-axis of the environment's coordinate system. Next, these pitch androll values are used to refine the magnetometer readings (process action1004). Then, in process action 1006, the previously computedmagnetometer correction factors are applied to the refined magnetometervalues. Finally, the yaw angle is computed from the refined andcorrected magnetometer values (process action 1008).

Specifically, the range-normalized accelerometer values representing thepitch and roll are used to establish the rotation matrix R_(a1,a2,0),which represents a particular instance of the Euler angle rotationmatrix R_(θ) _(x) _(,θ) _(y) _(,θ) _(z) that defines the composition ofrotations about the x, y and z axes of the prescribed environmentalcoordinate system. Next, a 3-value vector m is formed from therange-normalized values output by the magnetometer. The pitch and rollthen corrects the output of the magnetometer as follows:m_(corrected)=R_(a1,a2) _(y) ₀m  (1)Let N be the output of the magnetometer when the pointer is held at(pitch, roll, yaw)=(0, 0, 0), as determined in the calibrationprocedure. Then, project onto the ground plane and normalize as follows:

$\begin{matrix}{{{m_{projected} = {\begin{bmatrix}1 & 1 & 0\end{bmatrix}^{T}m}},{N_{projected} = {\begin{bmatrix}1 & 1 & 0\end{bmatrix}^{T}N}}}{{m_{{{normalized}\&}{projected}} = \frac{m_{projected}}{m_{projected}}},{N_{{{normalized}\&}{projected}} = \frac{N_{projected}}{N_{projected}}}}} & (2)\end{matrix}$And finally, the yaw angle is found as follows:yaw=sign(m _(np) ×N _(np))cos⁻¹(m _(np) ^(T) N _(np))  (3)The computed yaw angle, along with the pitch and roll angles derivedfrom the accelerometer readings, are then tentatively designated asdefining the orientation of the pointer at the time the orientation datamessage was transmitted by the device (process action 1010).

It is noted that there are a number of caveats to the foregoingprocedure. First, accelerometers only give true pitch and rollinformation when the pointer is motionless. This is typically not anissue except when the orientation computations are being used todetermine if the pointer is being pointed directly at an object. In suchcases, the problem can be avoided by relying on the orientationinformation only when the device is deemed to have been motionless whenthe accelerometer readings were captured. To this end, the orientation(i.e., pitch, roll and yaw) of the pointer is computed via the foregoingprocedure for the last orientation message received. This is thencompared to the orientation computed for the next to last orientationmessage received, to determine if the orientation of the pointer haschanged significantly between the orientation messages. If theorientation of the pointer did not change significantly, then thisindicates that the pointer was motionless prior to the transmission ofthe last orientation message. If the pointer was deemed to have beenmotionless, then the orientation information is used. However, if it isfound that a significant change in the orientation occurred between thelast two orientation messages received, it is deemed that the pointerwas in motion and the orientation information computed from thelast-received orientation message is ignored. Secondly, magnetic northcan be distorted unpredictably in indoor environments and in closeproximity to large metal objects. However, in practice, while it wasfound that for typical indoor office environments magnetic north did notalways agree with magnetic north found outdoors, it was found to befairly consistent throughout a single room. Thus, since theabove-described magnetometer correction factors relate the perceiveddirection of magnetic north in the environment in which the pointer isoperating to the prescribed coordinate system of that environment, whenthe environment is a room, it will not make any difference if theperceived direction of magnetic north within the room matches that inany other room or outdoors, as the orientation of the pointer iscomputed for that room only. Finally, it should be noted that theforegoing computations will not provide accurate results if theperceived magnetic north in the environment happens to be co-linear tothe gravity vector—a situation not likely to occur.

The foregoing designation of the pointer's orientation is tentativebecause it cannot be determined from the accelerometer reading used tocompute the roll angle whether the device was in a right-side up, orupside-down position with respect to roll when the accelerometer outputswere captured for the orientation data message. Thus, the computed rollangle could be inaccurate as the computations assumed the pointer wasright-side up. Referring now to FIG. 10B, this uncertainty can beresolved by computing the orientation assuming the pointer is right-sideup (process action 1012) and then assuming the pointer is up-side down(process action 1014). Each solution is then used to compute an estimateof what the magnetometer outputs should be given the computedorientation (process actions 1016 and 1018). It is then determined foreach case how close the estimated magnetometer values are to the actualvalues contained in the orientation message (process actions 1020 and1022). It is next ascertained whether the estimated magnetometer valuesfor the right-side up case are closer to the actual values than theestimated value for the upside-down case (process action 1024). If theyare, then the pointer is deemed to have been right-side up (processaction 1026). If, however, it is determined that the estimatedmagnetometer values for the right-side up case are not closer to theactual values than the estimated value for the upside-down case, thenthe pointer is deemed to have been up-side down (process action 1028).It is next determined if roll angle computed in the tentative rotationmatrix is consistent with the deemed case (process action 1030). If itis consistent, the tentative rotation matrix is designated as thefinalized rotation matrix (process action 1034). If, however, thetentative rotation matrix is inconsistent with the minimum error case,then the roll angle is modified (i.e., by 180 degrees) in process action1032, and the modified rotation matrix is designated as the finalizedrotation matrix (process action 1034).

One way to accomplish the foregoing task is to compute the orientation(R) as described above, except that it is computed first assuming thepitch angle derived from the accelerometer output reflects a right-sideup orientation of the pointer, i.e., Pitch_(right-side up)=−arcsin(a)where a is the normalized output of the accelerometer approximatelycorresponding to the rotation of the pointer about the x-axis of theenvironment's coordinate system. The orientation is then computedassuming the pitch angle derived from the accelerometer output reflectsan up-side down orientation of the pointer, i.e.,Pitch_(up-side down)=−π+arcsin(a). A separate estimate of what themagnetometer outputs (m*) should be given the orientation computed forthe right-side up condition and for the up-side down condition are thencomputed as follows:m*=R ^(T) N,  (4)where N is the direction of magnetic north. m* is the estimatedmagnetometer output assuming the pointer is in the right-side upcondition when R is the orientation computed assuming the pointer was inthis condition, whereas m* is the estimated magnetometer output assumingthe pointer is in the up-side down condition when R is the orientationcomputed assuming the pointer was in that condition. The error betweenthe estimated magnetometer outputs (m*) and the actual magnetometeroutputs (m) is next computed for both conditions, where the error isdefined as (m*−m)^(T)(m*−m). The pointer orientation associated with thelesser of the two error values computed is deemed to be the actualorientation of the pointer. It is noted that the roll angle derived fromthe accelerometer output could be used to perform as similar erroranalysis and determine the actual orientation of the pointer.

It is further noted that the 2-axis accelerometer used in the testedversions of the pointer could be replaced with a more complex 3-axisaccelerometer, or an additional 1-axis accelerometer or mercury switchoriented in the appropriate direction could be employed, to eliminatethe need for the foregoing error computation procedure. This would bepossible because it can be determined directly from the “third”-axisreadout whether the pointer was right-side up or upside-down withrespect to roll. However, this change would add to the complexity of thepointer and must be weighed against the relatively minimal cost of theadded processing required to do the error computation procedure.

As indicated previously, both the orientation and location of thepointer within the environment in which it is operating are needed todetermine where the user is pointing the device. The position of thepointer within the environment can be determined via various methods,such as using conventional computer vision techniques [1] or ultrasonicacoustic locating systems [2, 3]. While these methods, and their like,could be used successfully, they are relatively complex and oftenrequire an expensive infrastructure to implement. A simpler, less costlyprocess was developed for tested versions of the system and will now bedescribed. Specifically, the position of the pointer within theenvironment is determined with the aid of the two video camera havingIR-pass filters. The cameras are calibrated ahead of time to theenvironment's coordinate system using conventional calibration methodsto establish the camera parameters (both intrinsic and extrinsic) thatwill be needed to determine the 3D position of the pointing end of thepointer from images captured by the cameras. In operation, theaforementioned IR LED of the pointer is flashed for approximately 3milliseconds at a rate of approximately 15 Hz by the device'smicrocontroller. Simultaneously, both cameras are recording the scene at30 Hz. This means that the IR light in the environment is captured in1/30^(th) of a second exposures to produce each frame of the videosequence produced each camera. Referring to the time line depicted inFIG. 11, it can be seen that the flash of the IR LED will be captured inevery other frame of the video sequence produced by each camera due tothe approximately 15 Hz flashing rate. Referring now to FIGS. 12A and B,images depicting the scene at IR frequencies and capturing the flashfrom the pointer are shown, as produced contemporaneously from eachcamera. As can be seen, the IR LED flash appears as a bright spotagainst a background lower intensity IR noise. Referring now to FIG. 13,the procedure for ascertaining the location to the pointer in terms ofthe pre-defined coordinate system of the environment will be described.First, the image coordinates of the IR LED flash are determined in eachcontemporaneously captured frame from the cameras that depicts theflash. This is accomplished by first performing a standard subtractionprocess on a contemporaneously produced pair of frames from each of thecameras (process action 1300). The resulting difference images representthe scene with most of the background IR eliminated and the IR LED flashthe predominant feature in terms of intensity in the images, as shown inFIGS. 12C and D which depict the scene from the cameras captured in theimage of FIGS. 12A & B respectively once the background IR is eliminatedvia the subtraction method. A standard peak detection procedure is thenperformed on the difference image computed from each pair of framesproduced by each of the cameras (process action 1302). This peakdetection procedure identifies the pixel in the difference imageexhibiting the highest intensity. The image coordinates of this pixelare deemed to represent the location of the pointer in the image(process action 1304). Once the image coordinates of the pointer (asrepresented by the IF LED) are computed from a pair of images producedcontemporaneously by each camera, standard stereo image techniques(typically involving triangulation) are employed to determine the 3Dlocation of the pointer in the environment (process action 1306).

Once the pointer's location and orientation at a given point in time areknown it is possible to determine where the user is pointing inanticipation of affecting an object in the vicinity. There are numerousmethods that can be used to determine the pointed-to location and toidentify the object at or near that location. In tested versions of thesystem, a Gaussian blob scheme is employed to accomplish the foregoingtask. This entails first modeling all the objects in the environmentthat it is desired for the user to be able to affect by pointing at itwith the pointer, as 3D Gaussian blobs. In other words, the location andextent of the object is modeled as a single 3D Gaussian blob defined bythe coordinates of a 3D location in the environment representing themean μ of the blob and a covariance Σ defining the outside edge of theblob. These multivariate Gaussians are probability distributions thatare easily learned from data, and can coarsely represent an object of agiven size and orientation.

The modeling of the objects of interest in the environment as Gaussianblobs can be accomplished in any conventional manner. In tested versionsof the object selection system, two different methods were employed.Referring to FIG. 14, the first involves the user initiating a targettraining procedure that is part of the object selection process (processaction 1400), and then holding the button on the pointer down as he orshe traces the outline of the object (process action 1402). In addition,the user enters information into the process that identifies the objectbeing traced (process action 1404). Meanwhile, the target trainingprocedure causes a request to be sent to the pointer directing it toprovide an orientation message in the manner described previously(process action 1406). The orientation message transmitted by thepointer is inputted (process action 1408), and it is determined whetherthe button state indicator included in the message indicates that thepointer's button is activated (process action 1410). If not, processactions 1406 through 1410 are repeated. When, it is discovered that thebutton state indicator indicates the button is activated, then inprocess action 1412, the location of the pointer (as represented by theIR LED) is computed and recorded in the manner described above using theoutput from the video cameras. Next, a request is sent to the pointerdirecting it to provide an orientation message, and it is input whenreceived (process action 1414). It is then determined whether the buttonstate indicator still indicates that the pointer's button is activated(process action 1416). If so, process actions 1412 through 1416 arerepeated. If, however, it is discovered that the button state indicatorindicates the button is no longer activated, then it is deemed that theuser has completed the tracing task and in process action 1418, aGaussian blob is defined for the series of locations recorded during thetracing. Specifically, for recorded locations x_(i), the mean andcovariance of the these points is computed as follows:

$\begin{matrix}{{\mu = {\frac{1}{n}{\sum\limits_{i}x_{i}}}}{\sum{= {\frac{1}{n}{\sum\limits_{i}{\left( {x_{i} - \mu} \right)\left( {x_{i} - \mu} \right)^{T}}}}}}} & (5)\end{matrix}$The computed mean and covariance define the Gaussian blob representingthe traced object. This procedure can then be repeated for each objectof interest in the environment.

An alternate, albeit somewhat more complex, method to model the objectsof interest in the environment as Gaussian blobs was also employed intested versions of the object selection process. This method hasparticular advantage when an object of interest is out of the line ofsight of one or both of the cameras, such as if it were located near awall below one of the cameras. Since images of the object from bothcameras are needed to compute the pointers location, and so the pointsx_(i) in the tracing procedure, the previously described target trainingmethod cannot be used unless both of the cameras can “see” the object.

Referring to FIG. 15, this second target training method involves theuser first initiating the training procedure (process action 1500), andthen entering information identifying the object to be modeled (processaction 1502). The user then repeatedly (i.e., at least twice) points atthe object being modeled with the pointer and depresses the device'sbutton, each time from a different position in the environment withinthe line of sight of both cameras (process action 1504). When the usercompletes the foregoing action at the last pointing location, he or sheinforms the host computer that the pointing procedure is complete(process action 1506). Meanwhile, the training procedure causes arequest to be sent to the pointer directing it to provide an orientationmessage in the manner described previously (process action 1508). Theorientation message transmitted by the pointer is inputted (processaction 1510), and it is determined whether the button state indicatorincluded in the message indicates that the pointer's button is activated(process action 1512). If not, process actions 1508 through 1512 arerepeated. When, it is discovered that the button state indicatorindicates the button is activated, then in process action 1514, theorientation and location of the pointer are computed and recorded usingthe procedures described previously. It is next determined if the userhas indicated that the pointing procedure is complete (process action1516). If not, process actions 1508 through 1516 are then repeated asappropriate. If, however, the pointing procedure is complete, a ray thatprojects through the environment from the pointer's location along thedevice's orientation direction is established for each recorded pointinglocation (process action 1518). Next, the coordinates of the point inthe environment representing the mean of a Gaussian blob that is to beused to model the object under consideration, are computed (processaction 1520). This is preferably accomplished as follows. For eachpointing location:x _(i) +s _(i) w _(i)=μ  (6)where x_(i) is the position of the pointer at the i^(th) pointinglocation, w_(i) is the ray extending in the direction the pointer ispointed from the i^(th) pointing location, and s_(i) is an unknowndistance to the target object. This defines a linear system of equationsthat can be solved via a conventional least squares procedure to findthe mean location that best fits the data.

The covariance of the Gaussian blob representing the object beingmodeled is then established (process action 1522). This can be done in anumber of ways. First, the covariance could be prescribed or userentered. However, in tested versions of the target training procedure,the covariance of the target object was computed by adding a minimumcovariance to the spread of the intersection points, as follows:Σ=Σ₀+(x _(i) +s _(i) w _(i)−μ)(x _(i) +s _(i) w _(i)−μ)^(T)  (7)

It is noted that the aforementioned computations do not take intoaccount that the accuracy in pointing with the pointer is related to theangular error in the calculation of the device's orientation (and so inthe ray w_(i)). Thus, a computed pointing location that is far away fromthe object being modeled is inherently more uncertain than a computedpointing location which is nearby the target. Accordingly, the foregoingtarget training procedure can be refined by discounting the more remotepointing location to some degree in defining the Gaussian blobrepresenting an object being modeled. This can be accomplished using aweighted least squares approach, as follows:

$\begin{matrix}{{{W_{i}\left( {x_{i} + {s_{i}w_{i}}} \right)} = {W_{i}\mu}}{W_{i} = {\left( \frac{1}{{c\;{\hat{s}}_{i}} + \eta} \right)^{2}I}}} & (8)\end{matrix}$where W_(i) is the weight assigned to the i^(th) pointing location,ŝ_(i) is an estimate of the distance to the target object, possiblycomputed using the previous procedure employing the non-weighted leastsquares approach, c and η are parameters related to the angular error ofthe pointer, and I is the identity matrix. As before, Eq. (8) isgenerated for each pointing location to define a linear system ofequations that can be solved via the least squares procedure to find themean location that best fits the data, but this time taking intoconsideration the angular error associated with the computed orientationof the pointer.

It is noted that the foregoing procedures for computing the mean andcovariance of a Gaussian blob representing an object allow therepresented shape of the object to be modified by simply adding anynumber of pointing locations where the pointer is pointed along the bodyof the target object.

Once a Gaussian blob for each object of interest in the environment hasbeen defined, and stored in the memory of the host computer, the pointercan be used to select an object by simply pointing at it. The user canthen affect the object, as mentioned previously. However, first, theprocesses that allow a user to select a modeled object in theenvironment using the pointer will be described. These processes arepreformed each time the host computer receives an orientation messagefrom the pointer.

One simple technique for selecting a modeled object is to evaluate theGaussian distribution at a point nearest the mean of each Gaussianrepresenting an object of interest in the environment which isintersected by the a ray cast by the pointer, along that ray. Thelikelihood that the pointer is being pointed a modeled object i is then:l _(i) =g(x+∥μ _(i) −x∥w,Σ _(i))  (9)where x is the position of the pointer (as represented by the IR LED), wis a ray extending from x in the direction the pointer is pointed, andg(μ,Σ) is the probability distribution function of the multivariateGaussian. The object associated with the Gaussian blob exhibiting thehighest probability l can then be designated as the selected object.

Another approach is to project each Gaussian onto a plane normal toeither w or μ−x, and then to take the value of the resulting 2D Gaussianat the point where the ray w intersects the plane. This approach can beaccomplished as follows. Referring to FIG. 16, the ray that projectsthrough the environment from the pointer's location along the device'sorientation direction, is established (process action 1600). Inaddition, a line is defined between the mean point of each of theGaussian blobs and the pointer's location (process action 1602). Next,for each Gaussian blob a plane normal to the line between the blob meanand the pointer's location, or alternately a plane normal to the ray, isthen defined (process action 1604). Each Gaussian blob is then projectedonto the associated plane using standard methods, to define a 2DGaussian (process action 1606). The aforementioned ray is also projectedonto each of these planes (process action 1608). This projection may bea point if the ray is normal to the plane or a line if it is not normalto the plane. For each projected Gaussian, the likelihood that thepointer is being pointed at the associated object is computed based onhow far the origin of the projected Gaussian is from the closest pointof projected ray using standard methods (process action 1610).Essentially, the shorter the distance between the origin of theprojected Gaussian and the closest point of projected ray, the higherthe probability that the pointer is being pointed at the objectassociated with the Gaussian. Thus, in process action 1712, the Gaussianblob having the highest probability is identified. At this point theGaussian blob associated with the highest probability could bedesignated as the selected object. However, this could result in thenearest object to the direction the user is pointing being selected,even though the user may not actually be intending to select it. Toprevent this situation, a thresholding procedure can be performed.Referring to FIG. 16 once again, this thresholding procedure involvesdetermining if the probability computed for the Gaussian blob identifiedas having the highest probability exceeds a prescribed threshold(process action 1614). If the computed probability exceeds thethreshold, then the object associated with the Gaussian blob exhibitingthe highest probability is designated as being the object the user ispointing at (process action 1616). The threshold will vary depending onthe environment, but generally should be high enough to ensure an objectis actually being pointed at and that the user is not just pointing atno particular object. In this way, the process does not just pick thenearest object. Thus, if it is determined the computed probability theGaussian blob identified as having the highest probability does notexceed the prescribed threshold, then no object is selected and theprocedure ends. The foregoing procedure is then repeated upon receipt ofthe next orientation message, as indicated previously. It is noted thatthe thresholding procedure can also be applied to the first techniquefor selecting a modeled object, if desired.

It is further noted that the calculation associated with the weightedleast squares approach described above can be adopted to estimate theaverage angular error of the pointer without reference to any groundtruth data. This could be useful for correcting the computed pointerorientation direction. If this were the case, then the simplernon-weighted least squares approach could be employed in the alternatetarget object training procedure, as well as making the object selectionprocess more accurate. The average angular error estimation procedurerequires that the pointer be modified by the addition of a laserpointer, which is attached so as to project a laser beam along thepointing direction of the pointer. The user points at the object withthe pointer from a position in the environment within the line of sightof both cameras, and depresses the device's button, as was done in thealternate target object training procedure. In this case, this pointingprocedure is repeated multiple times at different pointing locationswith the user being careful to line up the laser on the same spot on thesurface of the target object. This eliminates any error due to theuser's pointing accuracy. The orientation and location of the pointer ateach pointing location is computed using the procedures describedpreviously. The average angular error is then computed as follows:

$\begin{matrix}{\sum\limits_{i}{\frac{1}{n}{{\cos^{- 1}\left( {w^{T}\frac{\mu - x_{i}}{{\mu - x_{i}}}} \right)}}}} & (10)\end{matrix}$wherein i refers to the pointing location in the environment, n refersto the total number of pointing locations, w is a ray originating at thelocation of the pointing device and extending in a direction defined bythe orientation of the device, x is the location of the pointing device,and μ is the location of the mean of the Gaussian blob representing thetarget object

Without reference to ground truth position data, this estimate of erroris a measure of the internal accuracy and repeatability of the pointerpointing and target object training procedures. This measure is believedto be more related to the overall performance of the pointer than to anestimate of the error in absolute position and orientation of thedevice, which is subject to, for instance, the calibration of thecameras to the environment's coordinate frame.

2.0 Gesture Recognition

As described above, the orientation and position of the pointer may befound by a combination of sensors and signal processing techniques. Thisallows an object, which is an electronic component controllable by acomputer via a network connection or an extension thereof, to beselected based on a geometric model of the environment containing theobject. The selection of a target object is accomplished by a usermerely pointing at the object with the pointer for a moment.

Once the object is selected, the electronic device can be controlled bythe user informing the computer in some manner of what he or she wantsthe device to do. As described above, this may be as simple asinstructing the computer to turn the device on or off by activating aswitch or button on the pointer. However, it is also desirable tocontrol device in more complex ways than merely turning them on or off.Thus, the user must have some way of relaying the desired command to thecomputer. One such way is by having the user perform certain gestureswith the pointer that the computer will recognize as particularcommands. This can be accomplished in a variety of ways.

One approach involves matching a sequence of sensor values output by thepointer and recorded over a period of time, to stored prototypesequences each representing the output of one or more sensors that wouldbe expected if the pointer were manipulated in a prescribed manner. Thisprescribed manner is the aforementioned gesture. The stored prototypesequences are generated in a training phase for each electroniccomponent it is desired to control via gesturing. To account for thefact that a gesture made by a user during runtime may differ from thegesture performed to create the prototype sequence in terms of speed andamplitude, the aforementioned matching process can not only entailcomparing a prototype sequence to the recorded sensor values but alsocomparing the recorded sensor values to various versions of theprototype that are scaled up and down in amplitude and/or warped in time(i.e., linearly stretched and contracted). The procedure used togenerate each prototype sequence associated with a particular gesture isoutlined in the flow diagram shown in FIG. 17. Specifically, the userinitiates a gesture training mode of the electronic component controlprocess running on the aforementioned host computer (process action1700). The user then inputs the identity of the electronic componentthat is capable of being controlled by the host computer and specifiesthe particular control action that is to be associated with the gesturebeing taught to the control system (process action 1702). Next, the useractivates the aforementioned button on the pointer and performs a uniquegesture with the pointer, which the user desires to represent thepreviously specified control action for the identified component(process action 1704). Finally, the user deactivates (e.g., releases)the pointer's button when the gesture is complete (process action 1706).Meanwhile, the gesture training process causes periodic requests to besent to the pointer directing it to provide orientation messages in themanner described previously (process action 1708). The process waits foran orientation message to be received (process action 1710), and uponreceipt determines whether the switch state indicator included in themessage indicates that the pointer's button is activated (process action1712). If not, process actions 1710 and 1712 are repeated. When, it isdiscovered that the button state indicator indicates the button isactivated, then in process action 1714, a portion of a prototypesequence is obtained by recording prescribed pointer sensor outputstaken from the last orientation message received. The process waits forthe next orientation message to be received (process action 1716), andupon receipt determines whether the switch state indicator included inthe message indicates that the pointer's switch is still activated(process action 1718). If so, process actions 1714 through 1718 arerepeated. If, however, the switch state indicator included in themessage indicates that the pointer's switch has been deactivated, thenit is deemed that the gesture has been completed, and in process action1720, the recorded values are designated as the prototype sequencerepresenting the gesture being taught to the system (process action1722). The foregoing procedure would be repeated for each controlgesture it is desired to teach to the component control system and foreach electronic component it is desired to control via gesturing.

During operation, the electronic component control system constantlymonitors the incoming pointer orientation messages after an objectassociated with a controllable electronic component has been selected,to assess whether the user is performing a control gesture applicable tothat component. This gesture recognition task is accomplished asfollows. Referring to FIG. 18, particular sensor readings obtained fromincoming orientation messages are first recorded for a prescribed periodof time to create an input sequence (process action 1800). Next,assuming more than one control gesture has been taught to the controlsystem for the electronic component under consideration, a previouslyunselected one of the prototype sequences representing the variousgestures applicable to the electronic component is selected (processaction 1802). If only one gesture was taught to the system for theelectronic component under consideration, then the associated prototypesequence for that gesture is selected. A similarity indicator is thencomputed between the input sequence and the selected prototype sequence(process action 1804). The similarity indicator is a measure of thesimilarity between the input sequence and the prototype sequence. Thismeasure of similarity can be defined in various conventional ways. Intested versions of the control system, the similarity indicator wascomputed as follows.

As mentioned above, the matching process can entail not only comparing aprototype sequence to the recorded sensor values but also comparing therecorded sensor values to various versions of the prototype that arescaled up and down in amplitude and/or warped in time. In testedversions, the amplitude scaling factors ranged from 0.8 to 1.8 inincrements of 0.2, and the time warping factors ranged from 0.6 to 2.0in increments of 0.2. However, while it is believed the aforementionedscaling and warping factors are adequate to cover any reasonablevariation in the gesture associated with a prototype sequence, it isnoted that different ranges and increments could be used to generate thescaling and warping factors as desired. In fact the increments do noteven have to be equal across the range. In practice, the prototypesequence is scaled up or down in amplitude by applying scaling factorsto each value in the prototype sequence. Whereas, the prototype sequenceis warped in time by applying warping factors that expand or contractthe overall sequence in time.

Essentially, a list is established before initiating the matchingprocess which includes every combination of the scaling and warpingfactors possible, includes the case where one or both of the scaling andwarping factors are zero. Note that the instance where both the scalingand warping factors are zero corresponds to the case where the prototypesequence is unmodified. Given this prescribed list, and referring now toFIG. 19, a previously unselected scaling and warping factor combinationis selected (process action 1900). Next, in process action 1902, theprototype sequence is scaled in amplitude and/or warped in time usingthe selected factor combination to produce a current version of theselected prototype sequence (which may be the prototype sequence itselfif the selected factor combination is zero scaling and zero warping). Aso called “match score” is computed between corresponding time steps ofthe input sequence and the current version of the prototype sequenceusing a standard Euclidean distance technique (process action 1904). Atime step refers to the prescribed sensor value or values taken from thesame pointer orientation message—i.e., the value(s) captured at the sametime by the pointer. Correspondence between time steps refers tocomputing the match score between the sensor values associated with thefirst time step in both sequences, then the second, and so on until thelast time step of the current version of the prototype sequence isreached. Once all the match scores have been computed they are summedand divided by the number of time steps involved, thereby producing anaverage match score (process action 1906). Thus, the average match scoreƒ(p_(i)(w,s),x) based on the aforementioned Euclidean distance functionƒ can be computed as follows:

$\begin{matrix}{{f\left( {{p_{i}\left( {w,s} \right)},x} \right)} = {\frac{1}{n}{\sum\limits_{t}\sqrt{\begin{matrix}\left( {{p_{i}\left( {w,s,t} \right)} - {x(t)}} \right)^{T} \\\left( {{p_{i}\left( {w,s,t} \right)} - {x(t)}} \right)\end{matrix}}}}} & (11)\end{matrix}$for selected warp w and scale s, where p_(i)(w,s,t) is the recordedsensor value(s) at time step t of the current version of the selectedprototype sequence i, x(t) refers to the corresponding sensor values ofthe input sequence at time step t, and n refers to the length of thecurrent version of the selected prototype sequence p_(i)(w,s) and so thelength of x as well, The foregoing process is then repeated for everyother combination of the warp and scale factors.

Specifically, it is determined if all the warp and scale factorcombinations from the prescribed list have been selected (process action1908). If not, the process actions 1900 through 1908 are repeated. Oncean average match score has been computed for every version of theprototype sequence (including the unmodified sequence), the maximumaveraged match score is identified (process action 1910). This maximumaveraged match score is the aforementioned similarity indicator for theselected prototype sequence.

Referring once again to FIG. 18, the similarity indicator is thencomputed for each remaining prototype sequence by first determining ifthere are any remaining unselected prototype sequences (process action1806). If so, then process actions 1802 through 1806 are repeated. Whena similarity indicator has been computed for every prototype sequence,it is next determined which of the similarity indicators is the largest(process action 1808). The prototype sequence associated with thelargest similarity indicator is designated as the best match to theinput sequence (process action 1810). The gesture associated with thedesignated prototype sequence is the most likely of the gestures thesystem has been trained for to match the pointer movements asrepresented by the input sequence. However unless the similarity isgreat enough, it might just be that the pointer movements are random anddo not match any of the trained gestures. This situation is handled byascertaining if the similarity indicator of the designated prototypesequence exceeds a prescribed similarity threshold (process action1812). If the similarity indicator exceeds the threshold, then it isdeemed that the user has performed the gesture associated with thatdesignated prototype sequence. As such, the gesture is identified(process action 1814), and the control action associated with thatgesture is initiated by the host computer (process action 1816).However, if the similarity indicator does not exceed the threshold, nocontrol action is initiated. The foregoing process is then repeatedcontinuously for each consecutive block of sensor values obtained fromthe incoming orientation messages having the prescribed length for aslong as the object associated with the electronic component underconsideration remains selected.

It is noted that the aforementioned prescribed length of the inputsequence is made long enough to ensure that the distinguishingcharacteristics of each gesture are captured therein. This aids inmaking sure only one gesture is recognized when several gestures areemployed in the system to initiate different control actions. In testedversions of the present system employing the foregoing match scoreprocedure this means making the input sequence as long as the longest ofthe scaled and warped version of the prototype sequence. Theaforementioned match score threshold is chosen similarly in that it ismade large enough to ensure that the distinguishing characteristics of agesture as captured in the prototype sequence actually exist in theinput sequence, and that the final match score computed for any otherprototype sequence associated with another gesture not having thesedistinguishing characteristics will not exceed the threshold.

As to the specific sensor output or outputs that are used to constructthe prototype sequences and the input sequence, any combination of theaccelerometer, magnetometer and gyroscope outputs contained in eachorientation message can be employed. It should be noted however, thatthe accelerometer will not provide an output indicative of the change inthe yaw angle of the pointer, and the gyroscope will only provide datareflecting a change in the yaw angle of the pointer. Thus, the usercould be restricted in the types of motion he or she is allowed to usein creating gesture if just the accelerometer or gyroscope outputs areemployed in the aforementioned sequences. Using fewer output values tocharacterize the gesture could result in lower processing costs incomparing the prototype and input sequences. However, to give the usercomplete freedom in choosing the types of motion used to define agesture, both the accelerometer and gyroscope outputs, or themagnetometer outputs, would have to be included in the sequences. Inaddition, while the processing costs would be higher, using the outputsfrom all three sensors could provide better accuracy in characterizingthe gesture motions.

The foregoing prototype matching approach has the advantage of allowingthe electronic component control system to be trained to recognizedgestures choreographed by the user, rather than requiring prescribedgestures to be used. In addition, the user can make the gesture assimple or as complex as he or she desires. A drawback of this approachhowever is that runtime variations of the gesture may involve more thansimple scaling of amplitude and linear time warps. Pattern recognitiontechniques that incorporate multiple training examples, such as hiddenMarkov models (HMMs) [8], may capture other important variations thatmay be seen in runtime. However, such techniques model only thosevariations present in the training data, and so would require the userto perform the desired gesture over and over during the trainingprocess—perhaps to the point of making the procedure unacceptablytedious. In addition, for gestures having a short duration, HMMs oftengive many false positives due to their nonlinear time warping abilities.Thus, the use of a HMM approach should be limited to user-createdgestures having longer durations.

In regard to the use of simple and short duration gestures, such as forexample a single motion up, down or to either side, an opportunityexists to employ a simplified and perhaps more robust approach togesture recognition. For such gestures, a recognition strategy can beemployed that looks for trends or peaks in one or more of the sensorvalues output by the pointer. For example, pitching the pointer up maybe detected by simply thresholding the output of the accelerometercorresponding to pitch.

In this case, the system is preprogrammed with gesture thresholddefinitions. Each of the definitions corresponds to a predefinedthreshold applicable to a particular single sensor output or a set ofthresholds applicable to a particular group of sensor outputs. Eachdefinition is associated in the process to a particular gesture, whichis in turn known to the system to represent a call for a particularcontrol action to be applied to a particular electronic component thatis controllable by the host computer. The thresholds are designed toindicate that the pointer has been moved in a particular direction withan excursion from a starting point which is sufficient to ensure thegesture associated with the threshold or thresholds has occurred. Thestarting point could be any desired, but for practical reasons, thestarting point in tested versions of the present control system waschosen to be with the pointer pointed at the selected object. Thus, itwas necessary for the user to point the pointing at the selected object.Pointing at an object establishes a local coordinate system around theobject, so that “up”, “down”, “left” and “right” are relative to wherethe object appears to the user. For example, “up” in the context of astanding user pointing at an object on the floor means pitching up froma pitched down position, and so on.

It would be possible for the electronic component control system todetermine when the user is pointing at the selected object using theprocedures described above in connection with determining what thepointer is pointing at for the purpose of selecting that object.However, a simpler method is to have the user depress the button on thepointer whenever he or she is pointing at the object and wants tocontrol the associated electronic device using a gesture. Requiring theuser to depress the button while gesturing allows the system to easilydetermine when a gesture begins. In other words, the system recordssensor values only after the user depresses the button, and thus gives anatural origin from which to detect trends in sensor values.

Recognizing gestures using a thresholding technique relies on thegestures being simple and of a short duration. One straightforward wayof accomplishing this would be to restrict the gestures to a singlemovement of the pointer in a prescribed direction. For example, onegesture could be to rotate the pointer upward (i.e., pitch up), whileanother gesture could be to rotate the pointer downward (i.e., pitchdown). Other examples of appropriate gestures would be to pan thepointer to the right (i.e., increase the yaw angle), or to the left(i.e., decrease the yaw angle). The sensor output or outputs used toestablish the gesture threshold definitions and to create the inputsequence to be discussed shortly are tailored to the gesture. Thus, theaccelerometer and/or the magnetometer outputs would be an appropriatechoice for the pitch up or pitch down gesture, while the gyroscopeoutput would not. Similarly, the gyroscope and/or the magnetometeroutputs would be an appropriate choice for the side-to-side gesture(i.e., changing the yaw angle), while the accelerometer output wouldnot. In general, when a simple one directional gesture is employed torepresent a control action, the sensor output or outputs that would bestcharacterize that motion are employed to establish the thresholddefinitions and the input sequence.

Given the foregoing ground rules, a procedure for gesture recognitionbased on a thresholding technique will now be described in reference toFIGS. 20A and B. The procedure begins with the user pointing to apreviously selected object in the environment that is associated with anelectronic component controllable by the host computer and holding downthe pointer's button (process action 2000). The user then performs theparticular gesture associated with the electronic component thatcorresponds to the desired control action (process action 2002).Finally, once the gesture is complete, the user releases the pointer'sbutton (process action 2004). Meanwhile, the periodic requests directingthe pointer to provide orientation messages continue to be sent in themanner described previously (process action 2006). The gesturerecognition process waits for an orientation message to be received(process action 2008), and upon receipt determines whether the switchstate indicator included in the message indicates that the pointer'sbutton is activated (process action 2010). If not, process actions 2008and 2010 are repeated. When, it is discovered that the button stateindicator indicates the button is activated, then in process action2012, prescribed pointer sensor outputs from the orientation message arerecorded. Then, a previously unselected one of the gesture thresholddefinitions associated with the selected object is selected (processaction 2014). Next, any threshold of the selected gesture thresholddefinition exceeded by the recorded sensor outputs applicable to thethreshold (i.e., associated with the same sensor output) is identified(process action 2016). There may be more than one. It is thenascertained if all the gesture threshold definitions associated with theselected object have been selected and processed (process action 2018).If not, process actions 2014 through 2018 are repeated until all thedefinitions have been processed. At this point, it is determined if allof the thresholds in one of the definitions have been exceeded (processaction 2020). If so, then it is deemed that the user has performed thegesture associated with that definition. As such, the gesture isidentified (process action 2022), and the control action associated withthat gesture is initiated by the host computer (process action 2024). Ifnot, then no control action is initiated. It is noted that this latterresult will only occur if the user improperly performed the desiredgesture procedure or if noise in the system prevented accurate sensorreadings from reaching the host computer.

3.0 Multimodal Integration

The complementary nature of speech and gesture is well established. Ithas been shown that when naturally gesturing during speech, people willconvey different sorts of information than is conveyed by the speech[4]. In more designed settings such as interactive systems, it may alsobe easier for the user to convey some information with either speech orgesture or a combination of both. For example, suppose the user hasselected an object as described previously and that this object is astereo amplifier controlled via a network connection by the hostcomputer. Existing speech recognition systems would allow a user tocontrol the volume by, for example, saying “up volume” a number of timesuntil the desired volume is reached. However, while such a procedure ispossible, it is likely to be more efficient and precise for the user toturn a volume knob on the amplifier. This is where the previouslydescribed gesture recognition system can come into play. Rather thanhaving to turn a physical knob on the amplifier, the user would employthe pointer to control the volume by, for example, pointing at thestereo and rolling the pointer clockwise or counterclockwise torespectively turn the volume up or down. The latter procedure canprovide the efficiency and accuracy of a physical volume knob, while atthe same time providing the convenience of being able to control thevolume remotely as in the case of the voice recognition control scheme.This is just one example of a situation where gesturing control is thebest choice, there are others. In addition, there are many situationswhere using voice control would be the best choice. Still further, thereare situations where a combination of speech and gesture control wouldbe the most efficient and convenient method. Thus, a combined systemthat incorporates the previously described gesturing control system anda conventional speech control system would have distinct advantages overeither system alone.

To this end, the present invention includes the integration of aconventional speech control system into the gesture control and pointersystems which results in a simple framework for combining the outputs ofvarious modalities such as pointing to target objects and pushing thebutton on the pointer, pointer gestures, and speech, to arrive at aunified interpretation that instructs a combined environmental controlsystem on an appropriate course of action. This framework decomposes thedesired action (e.g., “turn up the volume on the amplifier”) into acommand (i.e., “turn up the volume”) and a referent (i.e., “theamplifier”) pair. The referent can be identified using the pointer toselect an object in the environment as described previously or using aconventional speech recognition scheme, or both. The command may bespecified by pressing the button on the pointer, or by a pointergesture, or by a speech recognition event, or any combination thereof.Interfaces that allow multiple modes of input are called multimodalinterfaces. With this multimodal command/referent representation, it ispossible to effect the same action in multiple ways. For example, allthe following pointing, speech and gesture actions on the part of theuser can be employed in the present control system to turn on a lightthat is under the control of the host computer:

-   -   a). Say “turn on the desk lamp”;    -   b). Point at the lamp with the pointer and say “turn on”;    -   c). Point at the lamp with the pointer and perform a “turn on”        gesture using the pointer;    -   d). Say “desk lamp” and perform the “turn on” gesture with the        pointer;    -   e). Say “lamp”, point toward the desk lamp with the pointer        rather than other lamps in the environment such as a floor lamp,        and perform the “turn on” gesture with the pointer;    -   f). Point at the lamp with the pointer and press the pointer's        button (assuming the default behavior when the lamp is off and        the button is clicked, is to turn the lamp on).        By unifying the results of pointing, gesture recognition and        speech recognition, the overall system is made more robust. For        example, a spurious speech recognition event of “volume up”        while pointing at the light is ignored, rather than resulting in        the volume of an amplifier being increased, as would happen if a        speech control scheme were being used alone. Also consider the        example given above where the user says “lamp” while pointing        toward the desk lamp with the pointer rather than other lamps in        the environment, and performing the “turn on” gesture with the        pointer. In that example just saying lamp is ambiguous, but        pointing at the desired lamp clears up the uncertainty. Thus, by        including the strong contextualization provided by the pointer,        the speech recognition may be made more robust [5].

The speech recognition system employed in the tested versions of thepresent invention is Microsoft Corporation's Speech API (SAPI), whichemploys a very simple command and control (CFG) style grammar, withpreset utterances for the various electronic components and simplecommand phrases that apply to the components. The user wears a wirelesslapel microphone to relay voice commands to a receiver which isconnected to the host computer and which relays the received speechcommands to the speech recognition system running on the host computer.

There is still a question as to how to take in the various inputs fromthe pointer, gesture recognition and speech recognition events, some ofwhich may be complementary or even contradictory, and best determinewhat action the user wants performed and on what electronic component.While various computational frameworks could be employed, the multimodalintegration process employed in the present control system uses adynamic Bayes network [6] which encodes the various ways that sensoroutputs may be combined to identify the intended referent and command,and initiate the proper action.

3.1 Bayes Network

The identity of the referent, the desired command and the appropriateaction are all determined by combining the outputs of the speechrecognition system, gesture recognition system and pointing analysisprocesses using a dynamic Bayes network architecture. Bayes networkshave a number of advantages that make them appropriate to this task.First, it is easy to break apart and treat separately dependencies thatotherwise would be embedded in a very large table over all the variablesof interest. Secondly, Bayes networks are adept at handlingprobabilistic (noisy) inputs. And further, the network representsambiguity and incomplete information that may be used appropriately bythe system. In essence the Bayes network preserves ambiguities from onetime step to the next while waiting for enough information to becomeavailable to make a decision as to what referent, command or action isintended. It is even possible for the network to act proactively whennot enough information is available to make a decision. For example, ifthe user doesn't point at the lamp, the system might ask which lamp ismeant after the utterance “lamp”.

However, the Bayes network architecture is chosen primarily to exploitthe redundancy of the user's interaction so as to increase confidencethat the proper action is being implemented. The user may specifycommands in a variety of ways, even though the designer specified onlyobjects to be pointed to, utterances to recognize and gestures torecognize (as well as how referents and commands combine to result inaction). For example, it is natural for a person to employ deictic(pointing) gestures in conjunction with speech to relay informationwhere the speech is consistent with and reinforces the meaning of thegesture. Thus, the user will often naturally indicate the referent andcommand applicable to a desired resulting action via both speech andgesturing. This includes most frequently pointing at an object the userwants to affect.

The Bayes network architecture also allows the state of various devicesto be incorporated to make the interpretation more robust. For example,if the light is already on, the system may be less disposed to interpreta gesture or utterance as a “turn on” gesture or utterance. In terms ofthe network, the associated probability distribution over the nodesrepresenting the light and its parents, the Action and Referent nodes,are configured so that the only admissible action when the light is onis to turn it off, and likewise when it is off the only action availableis to turn it on.

Still further, the “dynamic” nature of the dynamic Bayes network can beexploited advantageously. The network is dynamic because it has amechanism by which it maintains a short-term memory of certain values inits network. It is natural that the referent will not be determined atthe exact moment in time as the command. In other words a user will nottypically specify the referent by whatever mode (e.g., pointing and/orspeech) at the same time he or she relays the desired command using oneof the various methods available (e.g., pointer button push, pointergesture and/or speech). If the referent is identified only to beforgotten in the next instant of time, the association with a commandthat comes after it will be lost. The dynamic Bayes network models thelikelihood of a referent or a command applying to future time steps as adynamic process. Specifically, this is done via a temporal integrationprocess in which probabilities assigned to referents and commands in thelast time step are brought forward to the current time step and areinput along with new speech, pointing and gesture inputs to influencethe probability distribution computed for the referents and commands inthe current time step. In this way the network tends to hold a memory ofa command and referent which decays over time, and it is thusunnecessary to specify the command and referent at exactly the samemoment in time. It is noted that in the tested implementation of theBayes network, this propagation occurred four times a second.

An example of a Bayes network architecture implemented for the presentelectronic component control system is shown in FIG. 21. As can be seen,the command node 2100 which is essentially a list of probabilities thata command recognizable to the system is the command the user wants toimplement, is influenced by input from a CommandLess1 node 2102representing the previous command probability distribution from the lasttime step. In addition, the command node 2100 is also influenced byinputs from other nodes indicating that the pointer button is activated(ButtonClick node 2104), a particular gesture has been performed(Gesture node 2106), an action has already been taken (ActionTaken node2108), and a particular speech command has been recognized(SpeechCommand node 2110). The ActionTaken node 2108 is set by thepresent program as a way to force the Command node 2100 to be cleared(i.e., to have no preference on the value of Command) once an action hasbeen taken. In this way the Command node 2100 will not cause an actionto be taken twice. Whereas, the referent node 2112, which is essentiallya list of probabilities that a referent controllable by the system isthe referent the user wants to affect, is influenced by input from aReferentLess1 node 2114 representing the previous referent probabilitydistribution from the last time step. In addition, the referent node2112 is also influenced by inputs from other nodes indicating that theuser is pointing at a particular target object (PointingTarget node2116) and that the user has specified a particular referent verbally(SpeechReferent node 2118).

The Command node 2100 and the Referent node 2112 (via a ReferentClassnode 2120) in turn influence the Action node 2122, as do various devicestate nodes represented by Light1 node 2124, Light2 node 2126 and Light3node 2128. The ReferenctClass node 2120 maps each referent to a classtype (e.g., Light1 and Light2 might both be “X10” type lights). Thisallows actions to be specified over a set of commands and the referentclass (rather then each referent instance). Such an approach is anefficient way of setting up the network as typically multiple referentsin an environment will work similarly. Without this node 2120, it wouldbe necessary to specify a command and action over each referent eventhough they would likely be the same within the same class of devices,

The device state nodes indicate the current state of a device where thatinformation is important to the control system. For example, if thedevice state nodes represent the state of a light (i.e., light 1), thenode could indicate if the light is on or off. It is noted that a devicestate node only influences the action node 2122 when the referent node2112 indicates that the electronic component associated with the devicestate node is the referent. Finally, a SpeechAction node 2130 can alsoprovide an input that influences the action node 2122 and so the actionultimately performed by the host computer. The speech action input is away to completely specify the Action from a single utterance, therebybypassing the whole dichotomy of Command and Referent. For example,SpeechAction node 2130 might map to a speech recognition utterance of“turn on the light” as a single unit, rather than saying “turn on”(Command) and “the light” (Referent). This node 2130 can also be usefulwhen an utterance does not fit into the Command/Referent structure, butmaps to Actions anyway. For example, the utterance “make it brighter inhere” can be mapped to an Action of turning on a light, even though nospecific Command or Referent was specified in the utterance.

Typically, the particular electronic component corresponding to thereferent, and in many cases the particular command given by the user toaffect the referent, dictate what the action is to be. However, theaforementioned device states can also play into this by restricting thenumber of possible actions if the device state applies to the referent.For example, assume the pointer is pointing at light 1. As a result thePointingTarget node in the Bayes network is “set” to Light1. This causesthe referent node to also be “set” to Light1, assuming there are noother contrary influencing inputs to the node. In addition, as thereferent is set to Light1, the state of this light will influence theAction node. Assume the light is on. Also assume there are only twopossible actions in this case, i.e., turn the light off if it is on, ordo nothing. Thus, the possible actions are limited and so when a commandin input (e.g., the speech command to “turn off”), the confidence levelwill be high that this is the correct action in the circumstances. Thisadded influence on the Action node causes the probability distributionof the node to collapse to “TurnOffLight”. The system then takes theappropriate action to turn off the light.

4.0 Experimental Results

A prototype of the foregoing electronic component control system wasconstructed and used to control a variety of devices in a livingroom-like scenario. Specifically, the user was able to control thefollowing electronic components using the pointer and a series of simplevoice commands.

4.1 X10 Lighting

A user is able to turn multiple lights in the room on and off bypointing the pointer at a light and depressing the button on thepointer. The user then utters the phrases “turn on” or “turn off”, asdesired to turn the light on or off. In addition, a selected light maybe dimmed or brightened via gesturing by respectively rotating thepointer down or up while pointing at the light.

4.2 A Media Player Running on a Computer

A user is also able to control a media player. Specifically, the userpoints the pointer at the host computer's monitor where the mediaplayer's GUI is displayed, and depresses the pointer's button to startthe player or to pause it. The user can also roll the pointer to theleft or right to change the volume, and can gesture up or down to movethe previous or next tracks in the play list. “Volume up”, “volumedown”, “next” and “previous” utterances command the player accordingly.

4.3 Cursor Control on a Computer Monitor

A user can point at a computer display and click the pointer's button togive control of the cursor to the pointer. The cursor is then movedaround the display's screen by pointing the pointer around the screen[7]. The pointer's button acts as the left mouse button. Clicking on aspecial icon in the corner of the display exits the cursor control mode.

4.4 Color Kinetics Lights

A user can also point the pointer at a special computer controlledarrays of red, green, and blue lights to brighten them over time. Whenthe user points away, the color gradually decays. Rolling the pointer tothe left or right changes the red, green and blue combination sent tothe light, changing the lights color.

5.0 Feedback Features

It is noted that for the prototype system, an audio feedback scheme wasemployed where an audible sound was generated by the host computer whenthe selected target changes. This audio feedback assures the user thatthe desired object has been selected, and therefore assists in theselection process. In addition, one of the aforementioned visiblespectrum LEDs on the pointer (in this case the green one) was lit via acommand from the host computer when the pointer was pointing at anobject known to the system.

It is noted that this feedback feature could be expanded beyond thatimplemented in the prototype. The pointer described previouslypreferably has two differently colored visible spectrum LED with whichto provide feedback to the user. For example, these could be used toindicate to the user that an input of some kind was not understood bythe component control system. Thus, if for instance the voicerecognition system did not understand a command or an identification ofa referent, the control system could cause one of the visible LEDs(e.g., the red one) to light up. The visible spectrum LEDs could even beused to provide the status of a device associated with an object thatthe user has selected. For instance, one of the LEDs could beilluminated to indicate the device was on, while the other wouldindicate the device was off. Or, for example, the intensity of one ofthe LEDs could be varied in proportion to volume setting on a stereoamplifier. These are just a few examples of the types of feedback thatthe visible spectrum LEDs can provide, many others are possible.

6.0 References

-   [1] Jojic, N., B. Brummitt, B. Meyers, S. Harris, and T. Huang,    Estimation of Pointing Parameters in Dense Disparity Maps. in IEEE    Intl. Conf. on Automatic Face and Gesture Recognition, (Grenbole,    France, 2000).-   [2] Priyantha, N.B., Anit Chakraborty, Hari Balakrishnan, The    Cricket Location-Support System. in Proceedings 6th ACM MOBICOM,    (Boston, Mass., 2000).-   [3] Randell, C., and Henk Muller, Low Cost Indoor Positioning    System. in Ubicomp 2001: Ubiquitous Computing, (Atlanta, Ga., 2001),    Springer-Verlag, 42-48.-   [4] MacNeil, D. Hand and Mind. University of Chicago Press, 1992.-   [5] Oviatt, S. L. Taming Speech Recognition Errors Within a    Multimodal Interface. Communications of the ACM, 43 (9). 45-51.-   [6] Pearl, J. Probabilistic Reasoning in Intelligent Systems. Morgan    Kaufmann, San Mateo, Calif., 1988.-   [7] Olsen, D. R. J., T. Nielsen, Laser Pointer Interaction. in    Proceedings CHI'2001: Human Factors in Computing Systems, (Seattle,    2001), 17-22.-   [8] Rabiner, L. R., Juang B. H., An Introduction To Hidden Markov    Models. IEEE ASSP Magazine (January 86) 4-15.

Wherefore, what is claimed is:
 1. A system for controlling an object viagesturing comprising: at least one camera for receiving light from adevice; a host computer coupled to the at least one camera forprocessing the received light to produce image data to determine a3-dimensional location of a gesture, wherein receiving light comprisesthe at least one camera periodically capturing images associated withthe light, and wherein the host computer processes the image dataagainst a coordinate system to determine the 3-dimensional location ofthe gesture; and a storage device coupled to the host computer forstoring a plurality of prototype sequences, wherein the host computerprocesses the image data to determine that the gesture has beenperformed by matching the image data against the plurality of prototypesequences, and wherein if the image data matches one of the prototypesequences a control action corresponding to the gesture is performed onthe object, wherein the storage device further comprises a list thatincludes one or more modified prototype sequences corresponding to eachof the plurality of prototype sequences, wherein the one or moremodified prototype sequences are different versions of a correspondingprototype sequence.
 2. The system of claim 1, wherein the modifiedprototype sequences are different from their corresponding prototypesequence in speed or amplitude.
 3. The system of claim 1, wherein themodified prototype sequences are different from their correspondingprototype sequence in time.
 4. The system of claim 1, wherein when thehost computer matches the image data against the prototype sequences, italso matches the image data against the corresponding modified prototypesequences.
 5. The system of claim 4, wherein if the image data matchesone of the modified prototype sequences, the control action for thecorresponding prototype sequence is performed on the object.
 6. Thesystem of claim 1, wherein matching the image data against the pluralityof prototype sequences comprises computing a similarity indicatorbetween the image data and each of the prototype sequences.
 7. Thesystem of claim 6, wherein after the similarity indicator between theimage data and each of the prototype sequences is computed, the hostcomputer determines a best match from one of the similarity indicators.8. The system of claim 7, wherein the host computer determines whetherthe best match exceeds a threshold and if the best match does not exceedthe threshold, the host computer determines that the gesture has notbeen performed and that the control action associated with the objectshould also not be performed.
 9. The system of claim 1, wherein one ofthe at least one cameras is an infrared camera.
 10. A method forcontrolling an object via gesturing comprising: receiving light with atleast one camera; capturing images caused by the light with the at leastone camera; producing image data from the light, said image datacomprising a user interacting with the object in a scene; generating alist that includes one or more modified prototype sequences for each ofa plurality of prototype sequences, wherein the modified prototypesequences are different versions of their corresponding prototypesequence; and matching the image data against the plurality of prototypesequences and their corresponding modified prototype sequences;determining whether the image data matches one of the prototypesequences; determining that a gesture has been performed by the user, ifthe image data matches the one of the prototype sequences, said gesturecomprising a movement performed by the user in a defined direction tointeract with the object; and performing a control action on the objectcorresponding to the gesture.
 11. The method of claim 10, wherein themodified prototype sequences are different from their correspondingprototype sequence in speed or amplitude.
 12. The method of claim 10,wherein the modified prototype sequences are different from theircorresponding prototype sequence in time.
 13. The method of claim 10,wherein determining that a gesture has been performed further comprisesdetermining that a gesture has been performed, if the image data matchesthe one of the modified prototype sequences corresponding to theprototype sequence.
 14. The method of claim 10, wherein matching theimage data further comprises: computing a similarity indicator betweenthe image data and each of the prototype sequences; and selecting one ofthe prototype sequences based on the similarity indicator.
 15. Themethod of claim 14, wherein selecting one of the prototype sequencesfurther comprises: determining a best match based on the similarityindicators; and determining if the best match exceeds a threshold. 16.The method of claim 15, wherein performing a control action furthercomprises: performing the control action on the object corresponding tothe gesture, if the best match exceeds the threshold; and performing noaction on the object, if the best match does not exceed the threshold.17. The method of claim 10, wherein one of the at least one camera is aninfrared camera.
 18. One or more computer-readable storage media in acomputing device having computer-useable instructions embodied thereonfor performing a method for controlling an object, the methodcomprising: receiving infrared light with at least one infrared camera;capturing images associated with the infrared light with the at leastone infrared camera; producing infrared image data from the infraredlight, said infrared image data comprising a user interacting with theobject in a scene; generating a list that includes one or more modifiedprototype sequences for each of a plurality of prototype sequences,wherein the modified prototype sequences are different versions of theircorresponding prototype sequence; and matching the infrared image dataagainst the plurality of prototype sequences and their correspondingmodified prototype sequences; determining whether the infrared imagedata matches one of the prototype sequences; determining that a gesturehas been performed by the user, if the infrared image data matches theone of the prototype sequences, said gesture comprising at least one ofa movement performed by the user in a defined direction to interact withthe object or speech uttered by the user to interact with the object;and performing a control action on the object corresponding to thegesture.
 19. The one or more computer-readable storage media of claim18, wherein the modified prototype sequences are different from theircorresponding prototype sequence in speed or amplitude.
 20. The one ormore computer-readable storage media of claim 18, wherein the modifiedprototype sequences are different from their corresponding prototypesequence in time.
 21. The one or more computer-readable storage media ofclaim 18, wherein determining that a gesture has been performed furthercomprises determining that a gesture has been performed, if the infraredimage data matches the one of the modified prototype sequencescorresponding to the prototype sequence.
 22. The one or morecomputer-readable storage media of claim 18, wherein matching theinfrared image data farther comprises: computing a similarity indicatorbetween the infrared image data and each of the prototype sequences; andselecting one of the prototype sequences based on the similarityindicator.
 23. The one or more computer-readable storage media of claim22, wherein selecting one of the prototype sequences further comprises:determining a best match based on the similarity indicators; anddetermining if the best match exceeds a threshold.
 24. The one or morecomputer-readable storage media of claim 23, wherein performing acontrol action further comprises: performing the control action on theobject corresponding to the gesture, if the best match exceeds thethreshold; and performing no action on the object, if the best matchdoes not exceed the threshold.